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1.  Introduction 


Data  flow  diagrams  are  a  commonly  used  tool  of  systems'  analysis,  and 
are  used  by  many  of  the  current  structured  methods  for  system 
development.  They  are  used  to  represent  pictorially  the  data  flows  within 
a  required  system,  showing  how  data  enters  and  leaves  the  system, 
what  changes  the  data,  and  where  the  data  is  stored.  As  such  they  are 
an  important  technique  for  understanding  and  communicating  the 
functionality  of  the  system. 

Data  flow  diagrams  contain  four  types  of  symbols  (elements).  These  are: 

1.  External  entity:  a  source  or  recipient  of  data  outside  the 
system,  represented  by  a  rectangle. 

2.  Process:  an  activity  which  transforms  or  manipulates  data, 
represented  by  a  circle. 

3.  Data  store:  a  collection  of  any  type  of  data  in  any  form, 
represented  by  two  parallel  horizontal  lines. 

4.  Data  flow:  showing  a  movement  of  data,  represented  by  an 
arrow  with  the  arrow  head  indicating  the  direction  of  flow  and 
a  label  showing  what  data  is  involved. 

Earlier  work  (1)  developed  formal  translation  rules  for  generating  a 
specification  in  the  formal  language  Z  (2,3)  from  such  diagrams. 
However,  the  specification  generated  was  an  outline  only,  and  contained 
no  information  on  the  types  of  the  data  flowing  round  the  system  or  on 
what  data  is  actually  kept  in  each  data  store. 

The  reason  for  this  lack  of  detail  is  that  the  information  from  which  the 
tj'pes  of  the  data  can  be  deduced  docs  not  appear  on  a  data  flow  diagram. 
Data  flows  arc  only  labelled  with  the  name  of  the  data,  and  do  not  say 
anything  more  about  the  composition  of  that  data.  Rather,  an 
accompanying  data  dictionary  contains  details  about  the  data  and  also 
details  of  what  data  is  stored  in  the  data  stores. 

The  purpose  of  this  report  is  to  explain  how  the  information  in  a  data 
dictionary  may  be  incorporated  into  the  Z  specification  generated  from 
the  relevant  data  flow  diagram.  A  fuller,  more  complete  Z  specification 
will  then  result. 

The  strategy  is  to  provide  formal  translation  rules  from  a  data  dictionary 
to  Z.  This  is  achieved  in  the  same  manner  as  that  used  for  the  original 
translation  from  data  flow  diagrams  into  Z  in  (!].  That  is,  the  data 
dictionary  is  specified  in  Z,  and  an  abstract  syntax  for  the  relevant  parts 
of  Z  specified,  again  in  Z.  A  function  is  then  defined  between  the 
specification  of  data  dictionaries  to  the  abstract  syntax  of  Z,  which  gives 
the  meaning  of  the  data  dictionary  in  Z  This  meaning  function  gives  the 
translation  rules 
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The  remainder  of  this  report  is  structured  as  follows.  Section  2  describes 
the  particular  form  of  data  dictionary  which  has  been  used  for  this 
work,  and  gives  some  examples  of  data  dictionary  entries  and  the 
equivalent  Z.  Section  3  presents  the  specifications  of  the  data  dictionary, 
Z  and  the  translation  rules,  and  section  4  contains  the  conclusions.  An 
updated  version  of  the  translation  from  data  flow  diagrams  into  Z, 
incorporating  the  information  from  the  data  dictionary,  is  given  in  the 
annex. 


The  particular  form  of  data  representation  chosen  for  this  work  is  that 
defined  in  [4].  This  notation  is  based  on  the  three  basic  operations  of 
sequence,  selection  and  iteration.  The  notation  is  summarised  in  the 
foliowing  table: 


This  particular  notation  has  been  chosen  because  it  is  well  used,  easy  to 
understand  and  is  well  defined.  The  three  basic  operations  are  those 
used  in  structured  programming  and  in  methods  like  JSD  (Jackson 
System  Development). 

To  give  an  idea  of  how  a  data  dictionary  expressed  in  this  notation  looks, 
consider  the  following  examples.  The  data  dictionary  contains  an  entry 
for  all  types  of  the  data  in  the  system,  so  that  the  type  of  every  data  flow  is 
defined. 

Example  1 

A  data  type  which  represents  all  the  days  of  the  week  will  be  represented 
as: 

DaysOffheWcek  =  (  Monday  I  Tuesday  I  Wednesday  I  Thursday 
1  Friday  I  Saturday  I  Sunday ) 

So  each  element  of  the  type  is  one  of  the  days  Monday  to  Sunday.  This  is 
a  selection  type.  The  selections  do  not  have  to  be  simple  as  in  this 
example,  but  can  be  any  type. 

Example  2 

An  iterated  type  is  one  in  which  a  component  is  lepcated  some  number 
of  times.  For  example,  a  bank  statement  is  composed  of  a  number  of 
transactions,  and  may  be  represented  as: 

Statement  =  ( Transaction  1 


i 
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Iterated  types  may  be  annotated  with  lower  and  upper  ranges,  to 
constrain  the  number  of  iterations.  This  has  the  form  mi  —  )n  where  m 
and  n  are  both  greater  than  or  equal  to  zero  and  m  is  not  greater  than  n. 
If  no  range  is  given  it  is  assumed  that  the  component  may  be  repeated 
some  arbitrarily  large  number  of  times.  This  ensures  the  iteration  type 
is  finite.  The  type  between  the  braces  may  be  as  complicated  as  is 
desired,  for  example  it  could  be  a  composite  type,  or  a  selection  type. 

Rxamnle  .1 

The  third  sort  of  type  is  a  composition  type.  The  bank  transactions  from 
the  previous  example,  is  one  of  these.  It  is  a  combination  of,  say,  the  date 
of  transaction,  a  description  of  the  transaction  (for  example,  whether  it 
is  a  standing  order,  or  direct  debit,  or  cash  withdrawal,  etc.),  whether  it 
is  a  debit  or  credit,  and  the  amount  of  money  involved,  and  may  be 
represented  as- 

Transaction  =  Date  +  Description  +  DebitOrCredit  +  Amount 

As  before,  the  composite  parts  of  one  of  these  types  may  be  complicated. 
The  ordering  of  the  components  is  not  important. 

ExampkJ 

If  we  do  not  wish  to  give  the  exact  details  of  a  type,  we  can  simpiy  give  a 
description  of  the  type.  The  description  is  a  simple  English  sentence, 
with  an  asterisk  at  each  end  to  denote  the  beginning  and  end  (rather  like 
a  comment  in  a  programming  language).  So,  for  example,  we  may  not 
wish  to  give  any  further  details  about  the  amount  of  money  involved  in  a 
transaction,  from  the  previous  example.  The  entry  for  "Amount"  in  the 
data  dictionary  would  then  be: 

Amount  =  •  The  amount  of  money  debited  (or  credited)  at  each 
transaction  * 

Descriptions  can  be  added  to  any  data  dictionary  entry,  to  help  the  reader 
understand  the  purpose  of  the  entry.  And  all  data  types  must  have  an 
entry  in  the  data  dictionary,  even  if  it  is  only  a  descnption. 

There  are  also  entries  in  the  data  dictionary  for  all  the  data  stores  which 
appear  on  a  data  flow  diagram.  The  diflercnce  with  a  data  store 
definition  is  that  the  key  of  the  store,  that  is,  that  part  of  the  data  store 
which  acts  as  an  'index'  into  the  store,  is  highlighted  (by  underlining). 
Consider  the  following  example. 

Examplt-S 

This  example  is  of  a  data  store  which  contains  a  bank's  database.  That 
IS,  each  entry  in  the  store  consists  of  the  bank  account  number,  the 
name  of  the  customer,  and  the  amount  in  the  account.  This  would  be 
represented  as- 

Bank  =  1  AccountN'o  +  Name  -f  Amount ) 
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This  is  an  iterated  type  because  a  bank  holds  many  accounts.  The 
account  number  is  the  key.  The  key  does  not,  in  general,  have  to  be  a 
single  component  but  may  be  a  compound  key  when  a  single  component 
is  not  suilicient  to  uniquely  identify  the  entry.  For  example,  a  telephone 
book  has  a  key  comprising  the  subscriber's  name  and  address,  as  the 
name  alone  is  not  suflident  to  find  the  'phone  number. 

To  motivate  the  translation,  consider  the  Z  equivalents  of  the  above 
examples.  The  first  was  a  selection  type,  and  it's  equivalent  in  Z  will  be  a 
free  type  as  follows: 

OoyeOfTheUeek  flondoy  |  Tuesdoy  |  Uednesday 

I  Thursday  j  Friday  |  Saturday  |  Sunday 

The  second  example  was  an  iterated  tj’pe.  The  nearest  equivalent  in  Z  to 
this  is  a  sequence,  as  follows: 

Stateoent  ■■  seq  Transaction 

where  Transaction  must  also  be  defined.  If  range  constraints  were 
used,  then  a  predicate  would  be  needed  to  say  that  all  statements  were  of 
an  appropriate  length.  For  example,  if  the  range  was  3  to  20,  so  that 
every  statement  had  to  contain  at  least  three  entries  but  no  more  than  20, 
then  the  following  constraint  would  be  needed: 

V  9  :  Staleaeni  •  3  ^  *9  ^  20 

The  third  example  was  a  composite  t>'pc.  The  nearest  equivalent  to  this 
in  Z  is  a  schema,  as  follows: 

•  Transaction  i 

da  :  Dote 
desc  :  Description 
d-or_c  :  DebitOrCredIt 
OD  ;  flaount 


where  Date,  Description,  DcbitOrCredit  and  Amount  must  be  defined. 
The  identifiers  da,  desc,  d.or.c  and  am  arc  added  to  the  Z  description  to 
make  the  schema  complete. 

The  fourth  example  had  no  actual  definition,  just  a  description.  The  Z 
equivalent  of  this  is  the  given  set,  as  follows: 

[  Raount  ] 

A  Z  specification  containing  such  a  given  set  should  also  have  an 
English  explanation  of  w'hat  the  given  set  represents,  which  will 
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probably  be  much  the  same  as  the  description  which  appears  in  the  data 
dictionary. 

And  the  final  example  is  of  a  data  store,  with  a  key.  This  is  again 
represented  in  Z  as  a  schema,  but  containing  a  function  from  the  key  to 
the  rest  of  the  data  store  entiy,  as  follows; 

p  Bonk  - - 

I  accounts  :  BccountNo  -r>  AccountDetoi  Is 
I _ , 


AccountNo  is  the  key  and  must  be  deiined  elsewhere.  AccountDetails  is 
a  schema  representing  the  type  of  the  rest  of  the  data  store  entry, 
constructed  in  the  same  way  as  that  for  a  composition  type.  Thus  the 
schema  AccountDetails  will  be  of  the  form; 

■  flccountOetoi Is  — , 
no  ;  Hone 
on  ;  Anount 


In  the  cases  where  the  key  is  compound,  that  is  where  it  has  more  than 
one  component,  a  schema  is  also  needed  to  represent  it,  constructed  in 
the  same  way.  The  identifiers  in  the  schemas  and  the  additional  schema 
names  themselves  must  be  added  to  produce  a  correct  Z  specification. 

The  formal  description  of  the  rules  for  translating  a  data  dictionary  into 
Z  are  given  in  the  following  section. 


3..Tran5littigainlp2 

3.1  The  Spcdlication  of  the  Data  Dictionary 

A  specification,  m  Z,  of  the  data  dictionary  is  needed  to  formalise  the 
data  dictionary  definitions  so  that  later  a  function  can  be  defined 
mapping  these  definitions  on  to  their  Z  equivalents. 

We  start  by  introducing  a  given  set  to  represent  the  description  of  each 
definition  in  the  data  dictionary. 

(  description  3 

The  description  is  textual,  but  we  need  not  be  concerned  about  its  exact 
form. 

[  definition  ] 
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The  actual  definitions  arc  recursive,  so  we  first  introduce  them  as  a 
given  set  There  are  five  sorts  of  definition:  compositions,  iterations, 
selections,  data  store  definitions  and  null  definitions.  The  null  definition 
occurs  when  just  a  description  is  given 

opcrotion  cooposition  |  iteration  |  selection 

The  three  basic  operations  arc  specified 

■  eoop.def  - , 

op  :  operation 
coaponente  :  definition 


op  •  coopoeition 
•cooponente  i  2 


The  first  kind  of  definition  is  a  composition  definition  This  has  the 
appropriate  operation  and  a  set  of  other  definitions,  which  are  the 
components  of  the  composite  type.  There  must  be  at  least  two 
components  for  the  definition  to  be  sensible  For  example,  consider  the 
composition  defimtion  given  above,  namely 

Transaction  =  Date  +  Description  +  DcbitOrCredit  +  Amount 

This  definition  has  the  set  of  components  (Date,  Description, 
DebitOrCredit,  Amount). 

•  iter.def  ■— . . . — . — . .  i 

op  :  opcrotion 
component  :  definition 
lower,  upper  :  IN 


op  ■  iterotion 
loner  i  upper 


An  Iteration  only  has  one  component,  the  type  between  the  braces.  This 
type  may  be  a  complicated  definition.  Lower  and  upper  range 
constraints  on  iteration  definitions  are  given,  to  restrict  the  number  of 
iterations.  For  example,  consider  the  iteration  definition  given  above, 
namely; 

Statement  =  !  Transaction ) 
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The  component  here  is  "Transaction",  the  lower  limit  is  0  (by  default) 
and  the  upper  limit  >'  jn  arbitrarily  large  number  (the  exact  number  is 
left  unspecified  as  it  \  -ill  depend  on  the  implementation). 

■  select.def  —  —  ■  , 

op  ;  opepotion 
coBponento  :  F]  definition 


op  •  selection 
•coaponente  I  2 


As  for  composition  Ijiies,  a  selection  type  has  the  appropriate  operation 
and  a  set  of  other  deHnittons,  which  are  the  components  of  the  selection 
tjpe.  Again  there  must  be  at  least  two  components  for  the  definition  to  bo 
sensible.  For  example,  consider  the  selection  definition  given  above, 
namely. 

DaysOfTheWeek  =  (  Monday  I  Tuesday  I  Wednesday  I  Thursday 
I  Fnday  I  Saturday  I  Sunday ) 

This  has  the  set  of  components  {Monday,  Tuesday,  Wednesday, 
Thursday,  Friday,  Saturday,  Sunday]. 


•  ds-def  — ~ 
key,  rest 

:  IF  definition 

'key  >  0 

A  data  store  definition  has  a  non-empty  key  which  identifies  the  rest  of 
the  data  store  contents.  For  example,  consider  the  data  store  definition 
given  above,  namely: 

Bank  =  {  AccoiintNo  +  Name  +  Amount ) 

This  has  key  (AccountNol  and  the  rest  is  the  set  (Name,  Account).  A 
data  store  may  have  no  other  contents,  but  just  have  a  key.  In  this  case, 
the  schema  generated  will  contain  just  a  set  of  the  key  elements  rather 
than  a  function 

definition  coiapccoBp_def>  j  iter<iter_def> 

I  eeleselect.defi  |  nuticseq  Chon  |  dscde.defi 

These  are  all  brought  together  to  form  the  free  type  describing 
definitions.  Null  definitions  just  have  identifiers  (names) 

We  can  now  construct  data  dictionarj-  entries 
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doto_dict_entry  — 
none  :  seq  Char 
def  :  definition 
deec  :  description 


def  c  rng  null  ■>  nulT'def  •  none 


Each  entry  has  a  name,  which  is  an  identifier,  a  definition  and  a 
description.  In  the  case  of  entries  with  null  definitions,  the  definition 
simply  uses  the  name  of  the  entry. 


doto.dict ior.jry  :  IP 

(seq  Char  -♦ 

♦  dolo-di client ry) 

Vdd:dolo_dlcl lonory 

•  Vn:doD  dd  • 

•  (dd  n)  .rtQDe  *  n 

A  data  dictionary  is  simply  defined  as  a  map  from  the  types  names  to 
their  entries.  Throughout  this  specification  it  has  been  assumed  that  the 
data  dictionary  is  sensible,  that  is  it  contains  only  valid  entries  and  does 
not  have  anything  like 

Bank  =  (Bank), 

for  example  If  the  dictionary  is  sensible,  a  useful  Z  specification  will  be 
produced.  On  the  other  hand,  if  the  dictionary  contains  some  circular 
definitions  or  other  incorrect  ones,  then  a  Z  specification  may  be 
generated,  but  will  contain  some  type  errors  which  may  be  found  using 
a  Z  type-checker  such  as  [3]. 

And  this  completes  the  Z  specification  of  the  data  dictionary. 

3.2  Tlic  Specification  of  Z 

In  order  to  provide  translation  rules  into  Z  using  the  strategy  desenbed 
in  section  1  above,  we  also  need  a  specification  of  the  relevant  parts  of  Z. 
This  specification  is  an  extended  version  of  that  given  in  (1).  The 
extension  is  to  encompass  Z  free  types  which  arc  needed  for  the 
translation  of  selection  types  in  the  data  dictionary,  to  allow  syntactic 
definitions  which  are  needed  for  the  translation  of  iteration  types  and  to 
allow  a  particular  sort  of  predicate. 

identifier  ■■  seq  Char 

We  start  by  introducing  identifiers,  which  arc  just  sequences  of 
characters  (strings).  To  specify  schemas  we  need  to  specify  names, 
signatures  and  predicates:  the  three  components  of  every  schema 

9chena_noBe  ■■  seq  Char 
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The  name  of  a  schema  is  just  a  sequence  of  characters.  The  signature  is 
more  complicated.  There  arc  two  sorts  of  elements  in  a  signature: 
inclusions  and  declarations.  Inclusions  arc  names  of  other  schemas  to 
be  included,  and  declarations  arc  (identifier, t>Tpe)  pairs.  Idenffiers  have 
already  been  defined.  Types  arc  more  difficult.  In  fact,  the  definitions  of 
types  and  signatures  arc  mutually  recursive,  so  a  set  of  all  possible  types 
is  first  introduced  as  a  given  set,  and  then  later  constrained. 

[  type  ] 

signoture.eleoenl  incescheoo-nooes 

I  dec<( ident i f ierxtype)> 

signoture  IF  signoture.elenent 

A  signature  is  a  set  of  signature  elements,  each  of  which  is  an  inclusion 
or  declaration 

Free  tjTpes  are  composed  of  a  set  of  branches. 

branch  sioplectypej  |  construct ed«( ident i fi epxtype)> 

Branches  are  either  simple  ones  consisting  of  the  name  of  a  set,  or  more 
complicated  ones  consisting  of  a  constructor  function  applied  to  a  type. 
For  example,  the  free  type  s  i  gnot  ure_el  eoent  above  has  two 
complicated  branches.  The  first  comprises  the  constructor  function  i  nc 
applied  to  the  sot  of  schema  names,  and  the  second  comprises  the 
constructor  function  dec  applied  to  the  set  of  (identifier, type)  pairs  Note 
that  the  sets  referred  to  are  actually  types  and  the  names  of  the 
constructor  functions  arc  identifiers. 

The  definition  of  t>T>es  can  now  be  completed. 

type  !;■  giuencseq  Chor>  |  tuplecseq  types 

poeereetetypes  |  echemo-typecsignotures 
freetypecIFi  bronchs 

There  arc  five  sorts  of  type  in  Z:  those  arising  from  given  sets;  tuple 
types,  arising  from  Cartesian  products;  powerset  types;  schema  types 
and  free  types. 

The  third  part  of  a  schema  is  the  predicate. 

(  ppedicote  ] 

I  eopty  :  ppedicote 
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Nothing  is  said  about  the  construction  of  predicates,  just  that  they  exist 
The  empty  predicate  is  defined. 

—  scheoo  1 

n  :  schefia.noDe 
dig  :  dignoture 
pred  :  predicate 


A  schema  has  a  name,  a  signature  and  a  predicate. 

Three  extra  %  elements  are  introduced.  First,  a  free  type  is  needed  for 
those  elements  defined  as  a  selection  in  the  data  dictionary.  Secondly,  a 
s>'ntactic  definition  is  needed  for  those  elements  defined  as  an  iteration. 
Thirdly,  a  predicate  is  needed  for  constraining  the  size  of  sequences 
produced  from  iterations. 

—  free_type_def  — — ■  » 

n  5  dCQ  Chor 
branched  :  bronch 

I _ , 


Free  type  definitions  have  a  name  and  a  set  of  branches. 

z.eleaent  gi ven.detcdeq  Char> 

free.type€free.tgpe...def>  |  box<dcheeio> 
dyn«def<deq  Charxtype> 
bounddcdeq  ChorxlNx?^> 

The  parts  of  Z  needed  are  given  sets,  free  types,  schemas,  a  particular 
form  of  syntactic  definition  and  a  particular  form  of  predicate.  The 
syntactic  definition  be  a  sequence  definition,  with  a  name  and  the 
type  of  the  elements  of  the  sequence.  The  function  syn.def  takes  this 
name  and  type  and  produces  a  Z  sequence.  The  predicate,  constructed 
using  the  function  bounds,  will  be  a  restriction  on  the  size  of  the 
sequence  corresponding  to  a  particular  iteration  definition. 

z.speci (icat ion  ■■  F  z-eleoent 

So  a  Z  specification  is  just  a  set  of  these  Z  elements.  At  a  more  concreto 
level,  a  Z  specification  is  actually  a  sequence  of  elements,  to  ensure  that 
rules  of  declaration  before  use  arc  followed.  However,  this  detail  is 
unnecessary  for  the  purpose  of  this  report.  This  completes  the 
specification 
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3^  The  TVansIation  Rules 

HaWng  specified  the  data  dictionary  and  the  necessary  parts  of  Z,  the 
next  stage  is  to  specify  the  meaning  function  which  provides  the 
translation.  There  arc  two  stages  in  this  process;  first,  a  function  which 
generates  the  appropriate  Z  type  from  each  data  dictionary  entry  must  be 
defined;  and  secondly,  the  function  to  translate  each  data  dictionary 
entry  into  the  Z  construct  which  will  appear  in  the  generated 
specification  must  then  be  defined. 

tran9lote_def  :  definition  — •  type 

The  function  to  generate  the  Z  types  will  be  defined  in  parts,  one  part  for 
each  of  the  sorts  of  definition  which  may  appear  in  a  data  dictionary, 
and  it  is  recursive.  Remember  that  each  data  dictionaiy  entry  has  three 
parts:  a  name,  a  definition  and  a  description;  and  that  there  arc  five 
sorts  of  definition:  compositions,  iterations,  selections,  data  store 
definitions  and  null  definitions. 

I  yet.ids  ;  signature  -*♦  f  identifier 


Vsig'signoture 

■  get-ids  sig  ■  fi ;  ioent i f ier; ty: type|dec( ! , tylcsig  ■  I) 


I  type_of  :  identifier  type 


I  in-bronch  :  identifier  <-»  type 

Extra  functions  are  needed  which  retrieve  the  identifiers  used  in  the 
signature  of  a  schema  from  that  signature,  associate  identifiers  with 
their  tjpes  and  relate  identifiers  and  types  which  together  make  up  a 
complicated  branch  of  a  free  type.  The  second  and  third  of  these  are  left 
unspecified. 

-  trons-pors  - p 

dd  :  definition 
It  ;  type 
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Composition  definitions  wll  be  translated  into  Z  schemas,  so  the  Z  typo 
they  give  rise  to  is  a  Z  schema  type  The  Z  schema  will  have  one 
component  Tor  each  of  the  components  of  the  composition,  so  the  schema 
type  has  a  signature  containing  one  declaration  for  each  of  these.  The 
actual  identifiers  which  appear  in  the  signature  arc  left  unspecified, 
and  an  anonymous  set  I  is  provided. 


zt*pooerset(tuple<giuen  ("Hot'), 


tronslote.def  (iter"'  dd)  coBponent>) 


Iteration  definitions  will  be  translated  into  sequences  In  Z,  sequences 
arc  really  functions  from  the  natural  numbers  to  the  type  of  the 
elements  of  the  sequence.  So  the  Z  type  for  an  iteration  is  a  powerset  type 
of  a  tuple  (sequences  are  just  functions  and  functions  are  really  just  sets 
of  pairs)  The  first  part  of  the  tuple  type  is  the  natural  numbers  (the 
domain  of  the  sequence),  and  the  second  part  is  the  type  of  the  iterated 
component  (the  range  of  the  sequence) 
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II  op  :  F]  identifier 


'ft  ■  'op  •  '(oei’’  dd).coBponents 
ft  ■  (o:op;ty!type 

I  ty  <  troneiote.def  ((eei''  dd)  .cooponento) 


(o,ty)  <  in_branch 


A  selection  definition  wil!  be  translated  into  a  Z  free  type.  Thus  the  Z  type 
generated  is  a  free  type,  and  it  has  the  same  number  of  branches  as 
there  are  components  in  the  selection.  Each  branch  is  constructed  from 
an  operation  (the  name  of  the  constructor  function),  and  the  type  of  one 
of  the  selection  components.  All  the  branches  generated  arc  complicated 
branches.  If,  by  later  examination,  it  was  realised  that  the  tyi>c  of  a 
selection  component  contained  only  one  element,  then  the  complicated 
branch  generated  for  that  element  could  be  replaced  by  a  simple  branch 
(the  constructor  function  would,  in  effect,  be  the  identity  function). 


I  ooke-def  i  definition  definition 


I  V  defs  I  Ft  definition;  def  :  definition 


■  def  •  oake_def  defe  «-» 

•defs  •  1  /V  (def)  •  defs 
V  'defs  >  I  /V  def  •  conp  cd 
ohere 

cd  :  coop-def 

cd.eosponents  •  defs 

A  preliminary  function  is  introduced  before  we  specify  the  translation  of 
a  data  store.  This  function  takes  a  set  of  definitions  and.  if  the  set  has 
more  than  one  clement,  it  generates  a  new  composition  definition  with 
components  being  those  in  the  original  set.  The  purpose  of  this  is  to 
allow  the  key  and  tlie  rest  of  the  elements  of  a  data  store  to  bo  treated 
exactly  the  same  as  composition  definitions  for  the  purpose  of 
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generating  Z  schemas  and  types  from  them.  For  example,  in  the 
example  given  in  section  2  above  of  a  data  store,  the  components  other 
than  the  key  (Name  and  Amount)  will  be  grouped  together  into  one 
composition  definition,  and  the  rules  for  translating  composition 
definitions  into  Z  applied  to  generate  the  schema  Account  Details. 

f-  trons-do  ■  > 

I  trons.poro 


dd  <  rng  ds 

zt  ”  sche&a.tgpe  (aig) 

ohcre 

sig  :  signoture 
i  :  identifier 
pt  5  type 


sig  ■  (  dec  <1,  pooerset  pt)  } 

*((ds*'  dd).rest)  ■  0 

^  pt  •  tronslote-def(ftQke-def((d9*'  dd).key)) 

V 

<Jd).resO  >  0 
A  pt  ■  tuple 

<  troftelote_det(Boke_def((d9''  dd).key)>, 
tronjlate_def(Buke.def((d9’'  dd).rest))  > 


Data  store  dermitions  will  also  be  translated  into  Z  schemas,  so  the  Z 
type  produced  is  a  schema  type.  As  in  the  final  example  in  section  2 
above,  the  signature  of  the  schema  contains  just  a  function,  mapping 
the  key  of  the  data  store  to  the  rest  of  the  components,  unless  there  are 
no  other  components  in  which  case  the  signature  contains  just  a  set  of 
the  key  elements. 

rtrons_null  - > 

trons.pors 


dd  c  rng  null 

zl  ■  given  (null''  dd) 


The  final  defimtion  is  the  null  definition  This  gives  nse  to  a  Z  given  set, 
with  name  the  same  as  the  definition 


Vtrana.pora  ■  zt  ■  tronalote.def  dd  «»»  trana-coep  v 
lrans_iter  v  trona.ael  v  trona.ds  v  trons-null 

Ail  these  parts  are  brought  together  to  deflne  the  function. 

We  can  now  define  the  function  which  translates  each  data  dictionary 
entry  into  its  equivalent  Z  construcUs). 

tronslote.entry  :  dota_dict_entry  — ♦  IF  z.clesent 

As  for  the  previous  case  this  translation  function  will  be  defined  in 
parts. 

—  trona-entry.pora  i 

dde  :  data_dict_entry 
ze  :  P  z-elecient 


—  tron3_entry«coap 
lrons_entry_pora 


dde  def  c  rng  coop 
ze  •  (  be-  a  ) 
ohere 

I  a  :  acheoo 


a  n  •  dde  none 
a.pred  •  eapty 

a.aig  ■  acheoo_type''  (tronalole_def  dde. def) 


The  Z  schema  generated  for  a  composition  definition  uses  the  name  of 
the  data  dictionary  entry  as  its  name,  and  has  an  empty  predicate.  Any 
predicates  constraining  the  values  of  the  entry  could  he  added  later  if 
desired. 
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r 

i 

^  |—  Irond-enlry-iler 

I  trons-enlry-pars 


dde.def  <  rng  iter 
ze  ■  (syn.def  (dde.noce, 

trondlote.def  (iler*^  dde.de O.cofiponent), 
bounds  (dde.nooe,  (iter‘*  dde.def).1oDer^ 
(Iter**  dde.def) .upper)} 


An  iteration  gives  rise  to  two  Z  constructs.  One  is  the  syntactic  definition 
which  defines  the  sequence  of  the  type  of  the  iterated  component,  and  the 
other  is  a  predicate  which  constrains  the  size  of  the  sequence. 

p  trons-entry^sel  "  '  i 

I  trons.entry-pore 


dde.def  <  rng  eel 
ze  ■  {  free.type  ftd  } 
ohere 

I  ftd  !  free-type-def 


ftd.n  ■  dde.nooe 

ftd. branches  ■  freetype**  (traneiote-def  dde.def) 


Selections  give  rise  to  a  Z  free  type.  Most  of  the  work  in  generating  this 
free  type  has  been  done  by  the  t rone  1  o t  e«de  f  function,  which 
generated  all  the  branches  of  the  free  type.  All  that  is  done  here  is  to  give 
the  free  type  an  appropriate  name. 

Data  stores  potentially  give  nse  to  three  schemas,  one  for  the  data  store 
itself,  one  for  the  key,  and  one  for  the  rest  of  the  components  of  the  store. 
Schemas  are  only  generated  for  the  last  two  of  these  if  they  contain  more 
than  one  element. 

p  trans-entry.ds-l  —  ..  , 

I  dde  :  dato_dict..enlry;  others  :  f  z.eleDent 


*(ds**  dde.def). key  •  1  *(d9**  dde.def)  .rest  i  1 

others  ■  {) 
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If  both  the  key  contains  only  one  element  and  the  rest  of  the  components 
contains  at  most  one,  then  no  extra  Z  element  is  generated. 

—  Iran3.-entry^d9_2  ■  — .  .  .  , 

dde  :  dato.dict^entry 
others  :  f  z^eleaent 


dde.def).key  ■  1  ’*(ds’'  dde. def) .rest  >  1 

others  ■  {  box  (t)  ) 
ohere 

I  t  :  scheoo;  tn  :  identifier 


t.n  ■  tn  type.of  tn  •  scheoo-type  t.sig 
t.pred  ■  eapty 
t.sig  ■  scheao-type’’ 

lranslote_def  (ooke-def  (ds*'  dde. def)  .rest) 


If  the  key  has  only  one  element  but  the  rest  of  the  components  has  more 
than  one.  then  one  schema  is  generated  to  represent  the  type  of  the  rest 
of  the  components.  This  schema  has  a  suitable  name,  an  empty 
predicate,  and  a  signature  constructed  by  translating  the  composition 
definition  made  from  the  rest  of  the  components  into  a  Z  schema  type. 

—  lrans,.entry,ds-.3  '  '  ■"  '  — '  — '  i 

dde  :  dota«dlct.»entry 
others  :  F  z^elenent 


“(ds*'  dde  def). key  >  1  **(d3'  dde , def ). rest  ^  1 

others  ■  <  box  (t)  ) 

ohere 


t 

:  scheaa;  tn  : 

i dent  i  f  i  er 

t, 

n  •  tn  /s  type- 

.of  tn  ■  scheno. 

-type 

t  .sig 

t , 

. pred  •  eapty 

t , 

. sig  ■  8cheno«type‘‘ 

tronslote.def 

(coke-def  (do'* 

dde . 

def) .key) 
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Similarly,  if  the  key  has  more  that  one  element  but  the  rest  of  the 
components  has  either  none  or  one,  then  one  schema  is  generated  to 
represent  the  type  of  the  key.  Again  this  schema  has  a  suitable  name,  an 
empty  predicate,  and  a  signature  constructed  by  translating  the 
composition  delinition  made  from  the  key  into  a  Z  schema  type. 

—  Irans^entry-do-l  — ■  —  i 

dde  :  doto.dict-entry 
others  :  F  z.ele&ent 


*(d3**  dde.def).key  >  1  ®(ds*’  dde.dcf ) .rest  >  1 

others  ■  {  box  (t),  box  (u)  ) 

ohere 

I  t,u  :  scheoo;  tn,  un  :  identifier 


t.n  ■  tn  A  type.of  tn  ■  scheeo_type  t.sig 
t.pred  ■  copty 

t. sig  «  scheao-type** 

tronslote-def  (aoke-def  (ds*’  dde  .def)  .key) 

u. n  ■  un  A  type.of  un  ■  scheno.type  u.sig 
u.pred  ■  eopty 

u.sig  •  scheao-type' 

tronslote.def  (nake-def  (ds'’  dde . def ). rest ) 


If  both  the  key  and  the  rest  of  the  components  have  more  than  one 
elements,  then  two  schemas  are  generated,  one  to  represent  the  type  of 
the  key  and  the  other  to  represent  the  t>'pe  of  the  rest  of  the  components. 
These  schemas  arc  constructed  jn  the  same  way  as  before. 


18 


—  trans.enlry.dd 
iron9»entry-pors 


dde.def  <  rng  dd  ze  »  {  box  a  )  u  others 
ohere 

s  :  schema;  others  :  IF  z^eleaent 


j  s.n  ■  dde.nofie  >s  s.pred  ■  eopty 

I  s.sig  ■  scheoQ-.lype‘*  (tronslate.def  dde.def)  i 

!  trQns-efttry«ds-1  v  lrons-entry_ds^2  v  trans»entry«ds-3 
I  V  traf>s«cntry«ds-4 


Finally,  the  schema  representing  the  data  store  itself  is  generated,  with 
the  same  name  as  the  data  dictionary  entry,  and  with  an  empty 
predicate.  The  other  Z  schemas  generated,  where  needed,  for  the  key 
and  the  rest  of  the  components  of  the  data  store,  are  combined  with  the 
schema  representing  the  data  store  to  give  the  total  set  of  Z  elements 
produced  from  a  data  store  definition 

p  trons.enlry.nul  I  ■  ■■  -  > 

I  trans-entry^pors 


I  dde.def  <  rng  null 
I  ze  ■  {  given-set  dde  name  ) 

I _ _ 

The  last  part  of  the  function  generates  a  Z  given  set  for  all  those  data 
dictionary  entries  which  just  have  descriptions. 

Vtrons-cntry.pors  •  ze  ■  translate-entry  dde 
trans-entry-conp  trons-entry-lter  v  trons-entry-sel 
V  trons-entry-ds  v  lrons-entry_nul 1 

All  these  parts  arc  brought  together  to  define  the  function 

I  translate-d_d  :  doto-dict lonary  — »  z_spec i f i cot i on 

_  I 


We  can  now  translate  the  whole  data  dictionary  into  a  Z  specification  by 
simply  applying  the  translate  entry  function  to  each  entry  in  the  data 
dictionary. 


4.  rxineliisiorts 

The  Z  specification  generated  from  a  data  flow  diagram  using  the  rules 
presented  in  (1)  is  an  outline  only.  In  particular,  no  information  about 
the  type  (composition)  of  the  data  flowing  around  the  system  is  present. 
The  formal  translation  presented  in  this  report  fills  that  gap  by  using 
the  data  dictionary  which  accompanies  each  data  flow  diagram  to 
generate  type  information  automatically.  The  Z  specification  generated 
from  the  diagram  and  dictionary  together  is  a  fuller,  more  useful 
specification. 

In  addition,  a  data  flow  diagram  says  nothing  about  the  content  of  each 
data  store  on  the  diagram,  whereas  the  data  dictionary  contains  an 
entry  for  each  describing  the  data  held.  Thus  the  Z  schema  generated 
from  the  diagram  for  each  data  store,  which  is  in  effect  an  empty 
schema  box,  should  be  replaced  by  the  schema  generated  from  the  data 
dictionary  description.  Again,  this  will  lead  to  a  more  useful  Z 
specification  being  produced. 

The  annex  to  this  report  combines  both  translations  into  one  formal 
translation  from  the  diagram  and  dictionary  together  into  a  single  Z 
specification. 

Thus  translations  have  been  developed  which  formalise  both  data  flow 
diagrams  and  their  accompanjing  data  dictionary,  and  which  enable  a 
useful  Z  specification  to  be  generated  automatically  from  them. 
However,  the  Z  specification  does  not  capture  the  communication 
aspects  of  the  data  flow  diagram  very  well,  so  is  still  limited,  especially 
when  the  data  flow  diagram  contains  mainly  communications  between 
processes  directly  and  not  via  data  stores  In  order  to  overcome  this 
deficiency  and  enable  communication  aspects  to  be  reasoned  about,  a 
translation  from  data  flow  diagrams  into  Hoare’s  CSP  (Communicating 
Sequential  Processes)  has  also  been  developed,  and  is  presented  in  [5) 


20 


Reforonces 


[1]  G  P  Randell,  Translating  Data  Flow  Diagrams  invO  Z  (and  vice 
versa),  RSRE  Report  90019,  October  1990 

[2]  C  T  Sennett,  Review  of  Type  Checking  and  Scope  Rules  of  the 
Specification  Language  Z,  RSRE  Report  87017, 1987 

[3]  G  P  Randell,  ZADOK  User  Guide,  RSRE  Memorandum  4356, 1990 

[4]  P  T  Ward  &  S  J  Mellor,  Structured  Development  for  Real-Time 
Systems,  Volume  1:  Introduction  and  Tools,  Yourdon  Press,  1985 

[5]  G  P  Randell,  Data  Flow  Diagrams  and  CSP,  RSRE  Report  (in 
preparation),  1992 


21 


INTENTIONALLY  BLANK 


Annei  -  TranslatiDg  Data  Flow  Diagrams  into  Z 


A,1  Introduction 

The  purpose  of  this  annex  is  to  bring  together  an  updated  version  of  the 
translation  from  data  flow  diagrams  into  Z  originally  presented  in  [1] 
and  the  translation  presented  in  the  main  part  of  this  report  to 
automatically  generate  a  more  useful  Z  specification.  The  same  strategy 
is  adopted,  in  that  first  a  specification  of  data  flow  diagrams  is  given, 
then  a  speafication  of  the  relevant  parts  ofZ,  and  finally  the  translation 
(meaning)  function. 

The  specification  of  Z  needed  for  this  translation  is  the  same  as  that 
given  in  section  3.2  of  the  main  part  of  this  report,  and  will  not  be 
repeated  in  this  annex.  The  translation  rules  presented  make  use  of  the 
data  dictionary  to  Z  translation  rules  from  section  3.3. 


A.2  The  Snocification  ofPata  Flow  Diagrams 

The  interpretation  put  on  a  data  flow  diagram  by  this  formalization  is 
that  it  represents  operations  being  earned  out  on  a  state.  The  state  is 
represented  by  the  data  stores,  and  the  operations  by  the  processes.  The 
external  entities  just  provide  or  receive  data. 

The  different  elements  of  a  data  flow  diagram,  namely  external  entities, 
processes  and  data  stores,  are  specified  first.  The  data  flows  between 
them  are  then  specified  as  constraints  on  the  set  of  diagram  elements 
that  make  up  a  given  diagram. 

f—  externol_ent ity  — . 

I  nones  ;  F  identifier 
I _ , 


The  relevant  part  of  an  external  entity,  from  the  point  of  view  of  this 
translation,  is  the  data  which  it  sends  to  and  receives  from  the  system. 
The  data  moving  around  the  system  is  shown  by  the  names  on  the  data 
flows.  These  names  are  modelled  as  simple  identifiers. 

Each  process  on  a  data  flow  diagram  inputs  data,  transforms  or 
manipulates  it,  and  produces  outputs. 

|—  process  - - 

inputs,  outputs  :  F  identifier 
reads,  writes  :  F  identifier 
process-none  seq  Chor 
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Inputs  and  outputs  come  from  or  go  to  other  processes  or  external 
entities  Communications  with  data  stores  are  treated  as  reads  or  writes 
of  the  state  data  held  in  the  store  (a  flow  from  a  process  to  a  data  store 
being  a  write,  and  the  reverse  direction  a  read).  The  inputs,  outputs, 
reads  and  writes  correspond  to  the  names  on  the  appropriate  data  flows. 
Processes  also  have  names,  which  are  intended  to  indicate  the  function 
that  the  process  performs. 

Data  stores  represent  the  state  of  the  system,  upon  which  processes  act 
by  reading  from  or  writing  to  them. 

—  datastorc -  —  > 

reads,  orltes  :  IF  identifier 
slore^nooe  :  seq  Chor 


Reads  from  and  writes  to  a  data  store  correspond  to  the  names  on  the 
flows  to  and  from  processes,  respectively.  Data  stores  also  have  names. 
The  contents  of  a  data  store  do  not  appear  on  a  data  flow  diagram,  so  no 
mention  of  contents  appears  in  this  specification. 

OFD.-elecient  ext  <  externol.ent  I ty  > 

I  proc  €  process  >  |  store  <  dotostore  > 

The  three  schemas  externoi.ent  Ity,  process  and  dotostore 
represent  the  three  possible  types  of  data  flow  diagram  element.  In 
addition  to  diagram  elements,  a  data  flow  diagram  also  contains  data 
flows 

p  doto.floo  •'  ■  . . . . 

I  origin,  dest  :  OFO-elenent 
I  label  :  ident i f  ier 


origin  *  dest 

origin  <  rng  proc  v  dest  <  rng  proc 


Each  data  flow  has  an  ongin  and  a  destination,  both  of  which  arc 
diagram  elements.  Each  is  also  labelled  with  the  name  of  the  data  which 
flows  along  it.  A  data  flow  cannot  be  circular,  in  that  it  cannot  return  to 
its  own  origin,  and  it  must  have  a  process  as  either  its  origin  or 
destination  (or  both).  This  prevents  external  entities  having  direct  access 
to  state  data  (except  via  processes  to  read  or  write  that  data),  and  also 
prevents  a  flow  between  two  data  stores,  a>  data  stores  arc  passive. 

A  well-formed  data  flow  diagram  consists  of  a  collection  of  diagram 
elements,  connected  by  suitable  data  flows.  The  first  check  is  on  the 
connectedness  of  the  diagram 
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—  Connected  - 

elenente  ;  F  OFO-elesent 
flooe  :  F  doto.flone 


Ve :el eoent s  •  (3f : floos  •  e  ■  {.origin  v  e  •  f.dest) 
Vfrflooe  .  ({.origin  c  eiecento  {.dest  c  eienento) 


The  (irst  predicate  says  that,  for  each  element  (external  entity,  process 
or  data  store),  there  must  be  a  data  How  either  from  it  or  to  it  (or  both). 
This  is  to  ensure  that  no  element  is  'orphaned'.  The  second  says  that  all 
{lows  must  be  connected  to  elements  in  the  diagram.  Further 
constraints  could  be  added,  if  required,  to  ensure  that  there  were  no 
sources  or  sinks  of  data  on  the  diagram,  or  that  the  diagram  was 
completely  connected  in  that  it  could  not  be  split  into  two  groups  of 
elements,  with  no  data  flows  between  any  two  elements  from  the 
different  groups. 

There  are  also  checks  on  a  data  flow  diagram  to  ensure  that  the 
representation  in  terms  of  elements  and  data  flows,  as  in  the  Z 
specification  above,  is  consistent  with  the  diagram.  The  first  check  is  on 
external  entities. 

-  Extepnol_ent it ies_ok  - > 

eleaents  :  F  OFO-eleaent 
floss  :  F  doto_{locs 


Ve ; el eaents;  ex;extepnoI_ent ity  |  e  •  ext  ex  ■ 
ex  noaes  •  ( {: floosje'f .op i g i n  v  e*{.dest  •  f.lobel) 


This  check  ensures  that  the  names  recorded  for  each  entity  correspond 
to  the  names  on  the  data  flows  to  and  from  that  entity 

The  second  check  is  on  processes 
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—  Procc99e8-ok  - - — 

eleaents  :  F  OFO^eleaenl 
f]oo3  :  IF  datQ.floss 


Ve:eleBenl3;  p:proce33  |  e  ■  proc  p  • 
p.  inputs  ■  origin  <  (rng  ext  u  rng  proc) 

f .dest  “  c  •  (. lobel ) 

p. outputs  ■  { f : f loos| f .or igin*e  ^  f.dest  c  (rng  ext  u 
rng  proc)  •  i . label } 

p.reods  ■  ( f : f loos  I f .or igin  c  rng  store  a  f. desire 
•  f.lobel) 

p.orites  ■  { f : floosj f.or igin^e  a  f.dest  c  rng  store 
.  f.lobel) 


This  schema  says  four  things  First,  that  the  inputs  to  a  process 
correspond  to  the  names  on  the  data  flows  to  that  process  from  cither 
external  entities  or  other  processes.  Secondly,  that  the  outputs  from  a 
process  correspond  to  the  names  on  the  data  flows  from  that  process  to 
either  external  entities  or  other  processes.  Thirdly,  that  the  “’reads"  a 
process  performs  corresponds  to  the  names  on  the  data  flows  from  data 
stores  to  that  process.  And,  fourthly,  that  the  "writes"  a  process 
performs  correspond  to  the  names  on  the  data  flows  from  that  process  to 
data  stores 

The  third  check  is  on  data  stores 

p  Dotostorcs-ok  ' '  > 

elenents  :  IF  OFO-eleoenl 
flogs  :  IF  dot o_f lows 


Veieleoents;  didotostore  |  c  •  store  d  • 
d. writes  •  {f;floos|f  origin  <  rng  proc  a  f.dest*© 
•  f.lobel) 

d. reads  ■  { f ; flows | f .or igin»e  a  f.dest  c  rng  proc 
.  f. label) 


This  check  ensures  that  the  data  wntten  to  a  data  store  corresponds  to 
the  names  on  the  data  flows  from  processes  to  that  data  store,  and  that 
the  data  read  from  a  data  store  corresponds  to  the  names  of  the  data 
flows  to  processes  from  that  data  store 
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-  dfd - 

eleaenld  :  ir  DFO^eleoent 
flood  :  IF  doto^flood 


i  Connected  /v  ExternQl.entilie9..ok  />.  Processes-ok  a 

Oolaslores.ok 


A  valid  data  flow  diagram  passes  all  the  checks. 


A3  The  SpgciGcation  of  the  Translation  Rules 

The  translation  takes  a  data  flow  diagram  and  its  accompanying  data 
dictionary  and  produces  a  Z  specification.  The  types  of  each  data  item 
are  found  from  the  data  dictionary,  as  are  the  data  store  schemas.  The 
diagram  gives  rise  to  one  operation  schema  for  each  process. 

We  first  need  to  relate  data  flow  diagrams  to  data  dictionaries. 

I  oppropriote  :  BFO  doto.dict ionory 


VdfdiOFDjddidoto.dictionory  •  apppopriote(dfd,dd) 
{dsidfd.eleoentsida  c  rng  store  •  (store"'  ds) . store-nose) 
u  (dfidfd. floss  •  df. lobel 1  S  don  dd 

A  data  flow  diagram  and  a  data  dictionary  arc  related  if  the  data 
dictionary  contains  an  entry  for  every  data  flow  (the  labels  on  data  flows 
are  the  names  of  the  data  types)  and  every  data  store  on  the  diagram. 
The  data  dictionary  must  also  contain  entries  for  all  definitions  which 
appear  as  components  of  an  entry.  Thus,  for  example,  if  a  data  flow  label 
"Address"  had  the  following  entry: 

Address  =  HouscNamc  +  Number  +  Street  +  Town  +  County 

then  the  data  dictionary  must  also  contain  individual  entries  for 
"HouseName",  "Number",  "Street",  "Town"  and  "County".  This 
'completeness'  constraint  is  left  unspecified,  it  should  be  noted  that  if 
the  data  dictionary  is  not  complete  then  the  Z  specification  generated 
will  simply  not  type-check 

The  translation  function  for  the  diagram  takes  each  process  from  a 
particular  diagram  with  Us  associated  data  dictionary  and  produces  an 
appropriate  Z  schema  which  describes  the  effect  the  operation 
represented  by  the  process  has  on  the  state  of  the  system.  That  is,  it 
desenbes  which  data  stores  are  affected  The  data  dictionary  is  used  to 
look  up  the  label  on  each  data  flow  to  find  the  type  of  the  data  flowing 
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The  signature  of  the  schema  generated  from  a  process  consists  of  just 
those  data  stores  which  are  read  by  the  process  but  not  altered  in  any 
way,  those  data  stores  which  the  process  does  affect,  and  the  inputs  and 
outputs. 

generote.reode  :  (process  x  DFD  x  dota.dict ionorg) 

•**  signoture 

Vp : process ;dfd:0F0; dd: dot o^dict i onorg 
I  proc  p  <  dfd.eleoeots  /<.  appropriote(dfd,dd) 

•  generote^reods  (p.dfd.dd)  • 

(  df :dfd. f loas;ds:datastore|store  ds  c  dfd.eleoents 
df.dest*proc  p  df .origln*store  ds 
•j(3df '  :dfd.  floos  •  df*  .origlft*proc  py^df '  .dest*store  ds) 

•  inc  ('S‘  ds.slore_naae)  ) 

Data  stores  which  are  read  by  the  process  but  not  altered  in  any  way  are 
prefixed  by  '3“  in  the  signature  of  the  schema  produced.  These  are  found 
by  looking  for  data  stores  in  the  diagram  from  which  there  is  a  data  flow 
to  the  process  in  question,  but  for  which  there  is  no  data  flow  in  the 
opposite  direction.  Each  data  store  which  is  the  destination  of  a  data  flow 
is  changed. 

generote.orites  :  (process  x  OFO  x  doto.dict ioftory) 
signature 

Vp j process ; d fd: OFO; dd: dot o_d let ionory 
I  proc  p  <  dfd.eleoents  ys  approprioteCdfd.dd) 

«  gencrote.ur i tes  (p.dfd.dd)  ■ 

(  df  :dfd.  floos;  dsMotostorc 
j  df .dest*3tore  ds  df .origin^proc  p  a 
store  ds  c  dfd.eleoents 
•  inc  (“A"  ds.store^noDe)  } 

Those  data  stor-  s  which  the  process  does  affect  are  prefixed  by  "A"  in  the 
signature  of  the  generated  schema 


I 


generote.ins  :  (process  x  OFO  x  doto.dictionarg) 

•**  signoture 

Vp :proce9d;dfd:0FD;dd:dQto.dict ionorg 
I  proc  p  4  dfd.el^aents  /v  oppropriote(dfd,dd) 

*  generote^ins  (p,dfd,dd)  * 

( i :p.  Inputs; ip: tdenl i f ier 

[last  lypc_of  Ip  ■  lpQn9iote_def((dd  O.def) 

•  dec  (ip^trondlote.def  (dd  D.def)) 

Inputs  arc  given  an  identiner  ending  with  in  the  signature  in  the 
usual  Z  style  The  types  of  these  are  found  by  looking  up  the  relevant 
cntr>’  in  the  appropriate  data  dictionary. 

gene''Ote.outs  :  (process  x  DFD  x  doto.dict  ionorg) 

•**  signature 

Vp' process, dfd  0F0;dddoto.dicl lonorg 
I  proc  p  <  dfd  elcaents  oppropriote(dfd,dd) 
generole.oots  (p,dfd,dd)  ■ 

{o;p  outputs;op* ident i f ier 

|1qsI  op«'*'/s  lype-of  op  ■  lron5lote«dcf((dd  o)  def) 

I  •  dec  (op,tronslote.de(  (dd  o)  deO) 

Similarly,  outputs  arc  given  an  identifier  ending  with  ‘ 

trons.proc  (processxOFOxdoto.d'Ct lonory)  -*♦  z. element 

Vp ■ process, d(d  0FD,dd  doto-dtet io^ory,ze  z-eleoent 
I  proc  p  «  dfd  elements  /s  opproprioie(dfd,dd) 

•  trans-proc  (p,dfd,dd)  ■  ze  <»*s  ze  ■  box  s 
where 

I  3  scheno 

I - 

SO"  p . process_none  s  pred  ■  eapty 
8  sig  ■  gencrole,.reods  (p,dfd,dd) 
u  generate_or Ites  (p,dfd,dd) 
u  generotc-ins  (p,dfd,dd) 
u  generote_outs  (p,dfd,dd) 

II  *3  s»g  ®  *(p  inputs  u  p  outputs  v  p  reods  v  p  writes) 


So  the  schema  generated  is  given  the  same  name  as  the  process  and  the 
empty  predicate  as  information  relating  to  the  predicate  part  of  the 
schema  does  not  appear  on  a  data  flow  diagram  nor  in  the  data 
dictionary.  The  four  functions  deflned  above  are  used  to  generate  the 
signature  of  the  schema,  which  has  one  element  for  each  read,  write, 
input  and  output. 

f  translate  :  (OFO  x  dato.dict ionary)  ■**  z.speci f icot ion 


V  dtd:0F0;  dd:doto..dict ionory  |  appropriote(dfd,dd) 

*  trcnslote  (dfd,dd)  ■  (p:process|proc  p  c  dfd.eleaents 
•  trons.proc  (p,dfd,dd))  u  trons]ote..d-d  dd 

To  generate  a  Z  speciflcation  from  a  data  flow  diagram  and  a  data 
dictionary  together  we  simply  translate  all  the  processes  on  the  diagram 
into  Z  schemas  and  and  put  these  together  with  all  the  type  definitions 
and  data  store  definitions  generated  from  the  data  dictionary  Note  that 
the  diagram  only  provides  the  processes,  that  is  the  operations  in  the  Z 
specification,  and  that  the  data  dictionary  must  be  appropnatc  for  the 
diagram  Thus  the  translations  into  Z  from  the  data  flow  diagram  and 
the  data  dictionary  cannot  be  inconsistent. 
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